BBS Toolkit/BBS Toolkit.iso/doors_1/aview64c.zip/WHATSUP.DOC

Text File | 1992-07-07 | 9KB | 192 lines

07/06/92

The v3.50 of WildCat has corrected the problem with line 30 in the DOOR.SYS
file.

05/17/92

Added a few new command line parameters.  Please review the AVIEWCOM.HST
file for details on changes, and AVIEWCOM.DOC for further information on
the new parameters.  Also, PKUNZIP v1.1 recognized -x and -e as parameters,
but the new PKUNZIP v1.93 only recognized -e.  Further, PKUNZIP v1.01 only
recognized -x.  I have chosen to use the -e parameter.  If you do not have
PKUNZIP v1.1 or newer, please upgrade to a newer version.

04/15/92

AViewCom will detect if DesqView is resident and will enable the patch
to prevent crashes.  Part of this is a pause for keypress before shelling
to an external program.  If your system does NOT crash while reading a
text file with earlier versions of AViewCom, then include the -q parameter
on the command line to disable this pause.

04/14/92

Thanks to some supportive help from Robert Cole from Mustang Software,
I have found a patch that seems to avoid the problem of AViewCom crashing
while running under some DesqView systems.  The problem resides either in
the gettext() or spawnlp() functions of TurboC as I am using them.  I will
be talking with Borland and QuarterDeck to come up with a true fix for the
problem.  For the moment, I have implemented a patch to hopefully avoid the
problem.  If you run a DesqView system, please let me know if you have any
trouble with "Reading a text file" or "Downloading a file" while using this
version.  There are many who have helped me over the years narrow in on this
problem.  I can't mention all of them, but I'd like to offer a special thanks
to Dave Codey, Minos Tsaussis, Pat Nefos, Scott Burch, and Rick Hemming.

04/05/92

PAK.EXE v2.51 is a memory hog and will take all remaining memory when
called.  With 400 kbytes free, PAK.EXE would not extract the file I
requested and gave no reason.  I guess the 400 kbytes wasn't enough.

03/30/92

In an attempt to loacate and fix the DV bug in AViewCom, I have
completely re-written and re-structured the code.  I had hoped that in
the process, to fix the bug which has caused DV users so many headaches.
However, I was unsuccessful.  I am now using the SMALL memory model
instead of the LARGE memory model to compile the program.  It will run
faster now.  It now uses 103 kbytes of memory.  Also, the maximum
filename capacity of files within an archive has been increased from a
limit of 255 to no limit.  The filenames are stored in a temporary file
called AVIEWLST.nnn where nnn is a number from 0 to 999 allowing 1000
nodes to use seperate temporary files simultaneously.  I have also
addes several useful new features to the program.  In addition, the
documention has been completely re-written.

03/11/92

I must apologize to several people for being so unavailable for the past
few months.  I've been involved in another project and worked 80 hours a
week for the last 15 weeks of 1991.  I spent the first couple months of
this year recovering.  I'm back now and am working on v6.2.  For DesqView
users, there was a mention of a STEALTH.TEC text file posted on Quarter
Deck SW Support BBS which has a fix for the memory conflict problem with
AViewCom.  I haven't read this, can someone let me know if this fix works?
Some DesqView users are not aware that DVANSI.COM should be loaded prior
to running WildCat to allow AViewCom to properly display ANSI characters.
Be sure to include DVANSI in your CAT.BAT batch file.

10/12/91

It has been brought to my attention that at times, AViewCom will report
that a user's download kbyte limit has been exceeded when they attempt
to download a file.  This happens sometimes because WildCat improperly
writes line 30 in DOOR.SYS.  It should write the DAILY DOWNLOAD KBYTES
TOTAL, but instead, it is writing the same value as line 48 which is
TOTAL DOWNLOAD KBYTES (from day one!).  Since AViewCom is used with
other types of BBS's and reads DOOR.SYS which is created properly by
them, I will not change AViewCom to adjust for this WildCat bug.  Instead,
WildCat SysOps should request a bug fix from Mustang.

10/10/91

For those running multi-nodes under DesqView, it has been discovered
that using LOADHIGH causes AVIEWCOM to lockup when attempting to
extract a file from an archive.  Removing the LOADHIGH operations
alieviated this problem in one DesqView installaion.

09/19/91

I have implemented the update user function by reading USERINFO.DAT
and modifying the last two lines to reflect the number of downloads
and download kbytes.  However, this is supposed to be a read/write
file but WildCat does not yet read this file back in and update the
allusers.dat file.  Since there is too much risk in corrupting the
database by having AViewCom update the database, the update user
function will not be active until WildCat reads back in the
USERINFO.DAT file.

09/05/91

AViewCom v6.1c is the first release which will read the DOOR.SYS
file.  I was amazed that the number of inquiries about this version
far exceeded the number of registrations I have received to date.
The shareware version has some functions disabled including reading
the DOOR.SYS file.  The shareware version will still run correctly
under WildCat v3.n even without reading DOOR.SYS.

08/25/91

Work has started on supporting WildCat v3.0.  I have added the
function to read in the DOOR.SYS file, but I still need more
information than is provided in that file:  system upload/download
ratio limit, and maximum download kbytes allowed.

06/08/91

Work will start soon on supporting the WildCat v3.0 databases.
I've spent multi-hours on the phone with two generous and helpful
sysops trying to debug the desqview problem with moderate progress.
The cause is still unknown, but I have found that pkunzip is NOT
the problem.  AViewCom locks up before getting to that point.

05/25/91

I have found several systems that have successuflly run WildCat
under DesqView with no problems, but other systems which will lock
up every time when AViewCom shells out to pkunzip.  My system with
a test copy of these programs works well.  The investigation as to
the cause of this problem with some systems locking up is ongoing.

04/21/91

The number one bug report currently is that AViewCom will lock-up
the system when shelling out to pkunzip and running under DesqView,
and WildCat.  I understand that with older versions of DesqView
and WildCat this did not happen.  I am planning on investigating
this problem further.

09/28/90

AViewCom now performs dynamic disk swapping.  There are five
modules within the program which are swapped out as they are used.
This will reduce the memory usage some, but the major memory usage
still remains with the archiver which AViewCom shells out to.  As a
note, PKUNZIP requires 260K of memory!  Also, VIEW.OVL is no longer
required.

08/21/90

I have tested AViewCom v4.4e with DesqView v2.26 with direct screen
writes enabled, and as far as I can tell (I'm not a DesqView
user!), it works okay - AViewCom doesn't overwrite other screens
when you're in other windows.  I have also added the PIF file which
you should review and change as needed.

07/04/90

Mustang has release v2.15.  I have had reports that the AVUSER
functions is not working properly with the new version.  I will
have this fixed with the next release which will also work under
DeskView and multi-node systems.

03/04/90

Mustang will soon be releasing a v2.15 which will create the CALLINFO.BBS
file when spawning out to the arcviewer.  I believe this file is different
from the one that aviewcom made but I don't know what yet.  AViewCom v4.5
will be able to use it, and will properly function in the avuser mode.
Sysops are cautioned on the use of the avuser function until this function
is verified with the new version.

01/01/90

I have incorported the functions of CALLINF2, AVSETUP, and AVUSER into
AVIEWCOM.  These are accessed by command line switches beginning with
a slash.  To invoke AVSETUP, type AVIEWCOM /S.  To invoke AVUSER, type
AVIEWCOM /U.  To invoke CALLINF2, type AVIEWCOM /C.

09/23/89

AViewCom will now update the user database to reflect: 1) total
downloads, 2) total download kbytes, 3) daily downloads, and 4)
daily download kbytes.  It does not update number of accesses for
the files downloaded (USERFILE.DAT is the only file altered).
The updating feature does not work with multi-node systems.
AViewCom v3 will be updated for the ShareWare market and will not
support WildCat v2.0.  AViewCom v4 will be updated for Registered
users only.  Mustang is working on a WildCat version 3 which will
eliminate the need for AVIEWCOM /C and AVIEWCOM /U.